Skip to content

feat: Implement restarter.stackable.tech/ignore label#410

Open
siegfriedweber wants to merge 10 commits intomainfrom
feat/ignore-restarter
Open

feat: Implement restarter.stackable.tech/ignore label#410
siegfriedweber wants to merge 10 commits intomainfrom
feat/ignore-restarter

Conversation

@siegfriedweber
Copy link
Copy Markdown
Member

@siegfriedweber siegfriedweber commented Mar 23, 2026

Description

Support the restarter.stackable.tech/ignore annotation on ConfigMaps and Secrets to exclude them from the restarter controller.

Rust edition updated to version 2024 to be able to use if-let-chains.

Part of stackabletech/issues#837

Definition of Done Checklist

  • Not all of these items are applicable to all PRs, the author should update this template to only leave the boxes in that are relevant
  • Please make sure all these things are done and tick the boxes

Author

  • Changes are OpenShift compatible
  • Changes approved: stackabletech/decisions#82
  • Helm chart can be installed and deployed operator works
  • Integration tests passed (for non trivial changes)
  • Changes need to be "offline" compatible
  • Links to generated (nightly) docs added
  • Release note snippet added

Reviewer

  • Code contains useful comments
  • Code contains useful logging statements
  • (Integration-)Test cases added
  • Documentation added or updated. Follows the style guide.
  • Changelog updated
  • Cargo.toml only contains references to git tags (not specific commits or branches)

Acceptance

  • Feature Tracker has been updated
  • Proper release label has been added
  • Links to generated (nightly) docs added
  • Release note snippet added
  • Add type/deprecation label & add to the deprecation schedule
  • Add type/experimental label & add to the experimental features tracker

@siegfriedweber siegfriedweber added release-note Denotes a PR that will be considered when it comes time to generate release notes. scheduled-for/26.7.0 labels Apr 1, 2026
@siegfriedweber siegfriedweber moved this to Development: Waiting for Review in Stackable Engineering Apr 2, 2026
@siegfriedweber siegfriedweber marked this pull request as ready for review April 2, 2026 14:00
@siegfriedweber siegfriedweber requested a review from sbernauer April 2, 2026 14:00
@sbernauer sbernauer changed the title feat: Implement annotation restarter.stackable.tech/ignore feat: Implement restarter.stackable.tech/ignore label Apr 7, 2026
Copy link
Copy Markdown
Member

@sbernauer sbernauer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly nits, only one concern about the watcher and label

authors = ["Stackable GmbH <info@stackable.tech>"]
license = "OSL-3.0"
edition = "2021"
edition = "2024"
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would have preferred a separate PR (as part of stackabletech/issues#832), but I followed https://doc.rust-lang.org/edition-guide/editions/transitioning-an-existing-project-to-a-new-edition.html and ended up with nearly the same changes, so LGTM


Label:: `restarter.stackable.tech/ignore`

If a ConfigMap or Secret is only used for initializing a StatefulSet or contains data which can be hot-reloaded, add the label `restarter.stackable.tech/ignore: "true"` to avoid unnecessary restarts of the StatefulSet pods:
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
If a ConfigMap or Secret is only used for initializing a StatefulSet or contains data which can be hot-reloaded, add the label `restarter.stackable.tech/ignore: "true"` to avoid unnecessary restarts of the StatefulSet pods:
If a ConfigMap or Secret is only used for initializing a StatefulSet or contains data which can be hot-reloaded, add the label `restarter.stackable.tech/ignore: "true"` to avoid unnecessary restarts of the StatefulSet Pods:

metadata_watcher(
cms,
watcher::Config::default()
.labels("restarter.stackable.tech/ignore != true"),
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing that came up to my mind: What happens when users add or remove the label from a ConfigMap/Secret?
Will e.g. adding this label result in a stale version to be cached forever? Maybe this optimization is actually not worth it 🤷

Comment on lines +295 to +300
.filter(|annotation| {
annotation
.0
.starts_with("restarter.stackable.tech/ignore-configmap.")
})
.map(|x| x.1)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I misread .0 and .1 and was confused why we store the key. This is a idea how we could name them. Optional, feel free to ignore
(same below)

Suggested change
.filter(|annotation| {
annotation
.0
.starts_with("restarter.stackable.tech/ignore-configmap.")
})
.map(|x| x.1)
.filter_map(|(key, value)| {
key.starts_with("restarter.stackable.tech/ignore-configmap.")
.then_some(value)
})

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or as an alternative

Suggested change
.filter(|annotation| {
annotation
.0
.starts_with("restarter.stackable.tech/ignore-configmap.")
})
.map(|x| x.1)
.filter(|(key, _)| key.starts_with("restarter.stackable.tech/ignore-configmap."))
.map(|(_, value)| value)


### Added

- Support the annotation `restarter.stackable.tech/ignore` on ConfigMaps and Secrets and the
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Support the annotation `restarter.stackable.tech/ignore` on ConfigMaps and Secrets and the
- Support the label `restarter.stackable.tech/ignore` on ConfigMaps and Secrets and the

@sbernauer sbernauer moved this from Development: Waiting for Review to Development: In Review in Stackable Engineering Apr 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

release-note Denotes a PR that will be considered when it comes time to generate release notes. scheduled-for/26.7.0

Projects

Status: Development: In Review

Development

Successfully merging this pull request may close these issues.

2 participants